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(57) ABSTRACT 
A common extensible software configuration markup lan- 
guage (XSCML) is used which is suitable to define a project 
related to the development or update of a software product. 
The common extensible software configuration markup lan- 
guage is preferably based on the Extensible Markup Lan- 
guage (XML). By means of the XSCML, a software project 
definition and a system independent software configuration 
framework are generated. An XSCML processor is provided 
to access the project definition and to describe product 
elements and processes and define their access parameters 
and their relations among each other. The framework is 
stored in the memory of one or more servers and in a 
database and has assigned the product elements, processes 
and tools in the memories. Selected ones of the product 
elements, tools and processes are called by at least one of a 
plurality of client workstations attached to the server by 
using the commands of XSCML. The servers may belong to 
geographically distributed computer systems which are con- 
nected through a communication network. Access and 
administration of the assigned product elements, processes 
and tools in the locally distributed systems and communi- 
cation between these systems is performed by XSCML data 
streams and commands, while editing of product elements 
may be performed in other programming languages which' 
are independent of the common extensible software con- 
figuration markup language. 
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SYSTEM AND METHOD FOR THE 
CONFIGURATION OF SOFTWARE PRODUCTS 

FIELD OF THE INVENTION 

[0001] The invention relates to a software configuration 
system and method for use in a computer system including 
at least one server which is connected to a plurality of 
clients. The system and method allow an efficient team 
cooperation to develop, update, build, promote, test and 
deliver product elements which are linked together to form 
different versions of a software package, and they also 
enable the definition of process and data flows for product 
elements through the software configuration system from 
creation and update to delivery. 

BACKGROUND OF THE INVENTION 

[0002] Software Configuration Management (SCM) envi- 
ronments are implemented as a loose set of tools to be 
combined. They differ with each installation. There is no 
platform independent technology to combine such tools and 
libraries under one company defined framework and devel- 
opment process model. Most of the time, the source code 
handling and control is separate from the compile (build) 
logic and other tools used. In addition, the source control 
libraries available maintain their own private format so that 
a user must perform check-outs and check-ins with regard to 
a file system. On the other side, the developers always prefer 
to work with the file system view because there they have 
the most tools available and it is transparent for the devel- 
oper. They prefer to do edit, compile (one form of a build), 
and debug operations with the look and feel of a file system, 
but also preferably want in the background to have all the 
advantages of a source control library to enable a team 
development structure. 

[0003] One problem of the prior art systems consists of the 
fact that the known implementations provide proprietary 
implementations which lack compatibility with other sys- 
tems. There exist elements on the way to a solution of this 
problem, but such elements do not provide an open and 
platform independent definition which enables a unique 
platform for the use of different operating systems, library 
implementations and tools. An example of a known system 
using a declarative approach is represented by the IBM 
product called "Software Configuration and Library Man- 
ager (SCLM)," which is part of the IBM OS/390 operating 
system family and is described in the IBM publication 
"Software Configuration and Library Manager (SCLM) 
Project Manager's Guide/' OS/390 Version 2, Release 5.0, 
publication no. SG28-1319-02, 1998, the disclosure of 
which is incorporated by reference herein. This product uses 
proprietary definitions for the elements controlled in a 
library system and for the functions provided, but it does not 
provide support for any library system and any operating 
system. It lacks however a built-in process flow support. 

[0004] Another known system is represented by a product 
called "TeamConnection," which is described in the IBM 
publication "Getting Started with the TeamConnection Cli- 
ents, Version 3.0" publication no. SC34-4552-02, 1998, the 
disclosure of which is incorporated by reference herein. 
"TeamConnection" does not use the declarative approach 
but contains certain functional elements like tracking 
approaches, data security and notification. Also, this system 
does not provide a platform independent support. 



[0005] Besides, in the known environments, the develop- 
ers work on a file system to do their jobs and just once in 
awhile they are interested in synchronizing their source with 
the back end library system to get the files saved and to 
update the library system to serve as a base for a common 
driver. However, the builds are not ensured to be common 
across all users and back end processes. 

[0006] Companies which are creating software products 
for their own business, or selling such products, need a 
development environment which ensures the following of 
defined rules and processes for different purposes such as 
security, quality, reliability and legal subjects, and supports 
any needed technology. None of the known products allow 
covering all the technologies and processes needed. How- 
ever, it would be highly advantageous for existing tools and 
products, with their functions and processes, to be built into 
a defined framework to integrate them into one well-defined 
solution. 

SUMMARY OF THE INVENTION 

[0007] It is an object of the invention to provide a software 
configuration system and method which allow an efficient 
team cooperation to develop, update, built, promote, test and 
deliver product elements which are linked together to form 
different versions of a software package. 

[0008] It is also an object of the invention to provide a 
software configuration system and method which enable a 
user to define process and data flows for product elements 
through the software configuration system from creation and 
update to delivery of a software package. 

[0009] It is another object of the invention to provide a 
common configuration markup language for handling a 
plurality of product elements stored in library systems. The 
common language is used to access product elements and to 
determine how the elements relate to each other with regard 
to inputs, outputs, logical dependencies and specific param- 
eters for the software packages to be developed or updated. 

[0010] It is a further object of the invention to provide a 
software configuration system and method which enable 
distributed team cooperation and build servers, provided by 
different manufacturers and controlled by different operating 
systems, to communicate among each other. 

[0011] It is also an object of the invention to provide a 
system and a method which permit the use of a central 
definition for access rules to the data and processes, for the 
process workflow, problem reporting, notification rules, 
build rules, promotion rules and edit rules within a software 
configuration environment in which a plurality of developers 
are involved who may reside in different locations remote 
from each other. 

[0012] In one aspect of the invention, a method comprises 
the step defining a common extensible software configura- 
tion markup language (XSCML) which is suitable to define 
a project, to perform a memory access to product elements 
and packages, and for mapping of the processes and tools to 
one ore more library systems and for defining the relations 
between the product elements. By using this common exten- 
sible software configuration markup language, a system 
independent software configuration framework is generated 
to describe the product elements and processes and define 
their access parameters and their relations among each other. 
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[0013] A system independent software configuration 
framework according to the invention may be stored in the 
memory of one or more servers, which have assigned the 
product elements, processes and tools in the memories. 
Selected ones of the product elements, tools and processes 
are called by at least one of the clients attached to the server 
or servers by using the commands of the common extensible 
software configuration markup language, while the users 
may use their own languages to develop, update or test the 
product elements called. The common software configura- 
tion markup language is preferably based on the Extensible 
Markup Language (XML). 

[0014] According to another aspect of the invention, a 
system independent software configuration framework 
according to the invention may be stored in the memories of 
a plurality of geographically distributed computer systems 
which are connected together through a communication 
network. Access and administration of the assigned product 
elements, processes and tools in the locally distributed 
systems and communication between these systems is per- 
formed by the common extensible software configuration 
markup language, while editing of product elements may be 
performed in other languages which are independent of the 
common extensible software configuration markup lan- 
guage. 

[0015] Using such an inventive approach permits an 
exchange of product elements with other locations where, in 
each of the cooperating locations, the same system behavior 
is provided, even if different implementations are used 
which may include different file systems and library sys- 
tems. The local library systems may even be reduced to pure 
file systems including in a database to hold some meta data 
for local elements all covered in the Web through Web 
technologies like WebDAV ("Web-based Distributed 
Authoring and Versioning," a set of extensions to HTTP 
(hypertext transport protocol) which allows users to collabo- 
ratively edit and manage files on remote web servers). 

[0016] Further, XSCML based definitions may be pro- 
cessed to create an environment documentation to be printed 
or accessible via the Web. This leads to environment defi- 
nitions which, on the one side, describe the technical con- 
structs needed for running the software configuration envi- 
ronment system, but also provide a self documenting 
approach of the same. To enhance the documentation capa- 
bilities, additional XML tags may be allowed similar to the 
HTML (hypertext markup language) tags to intersect the 
technical text to provide the commentary of the technical 
elements, on one side, but also allow to create user and 
administration documentation, on the other side, from the 
same source. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] FIG. 1 is a schematic block diagram of a known 
server computer usable for the implementations of the 
invention as shown herein; 

[0018] FIG. 2 is a general block diagram of a computer 
system adapted to execute an embodiment of the invention; 

[0019] FIG. 3 is a general block diagram of distributed 
computer systems adapted to execute another embodiment 
of the invention; 

[0020] FIG. 4A is a schematic block diagram of a soft- 
ware configuration system according to the invention; 

[0021] FIG. 4B is a schematic block diagram of the data 
flow between main components of a system according to the 
invention; 



[0022] FIG. 5 is a block diagram of a simplified example 
of a logical project view history defining the data flow of 
elements; 

[0023] FIG. 6 is a block diagram of the logical project 
view hierarchy of a software project which is developed and 
tested by using a method and system according to the 
invention; 

[0024] FIG. 7 is a subsection of a logical project view 
hierarchy showing the combination with a defined process 
flow; 

[0025] FIG. 8 is a physical member representation of a 
project which is developed and tested by using the system of 
FIG. 4; 

[0026] FIG. 9 is a block diagram of the logical project 
view with multiple hierarchies; 

[0027] FIG. 10 is a block diagram of the logical project 
view of a software project which is developed and tested by 
using the distributed systems according to FIG. 3; 

[0028] FIG. 11 is a block diagram of the project activation 
process for the cooperation of the distributed systems 
according to FIG. 3; 

[0029] FIG. 12 is a flow diagram of a process to initiate 
an XSCML system according to the invention; 

[0030] FIG. 13 is a flow diagram of a process to manage 
project definitions according to the invention; and 

[0031] FIG. 14 is a flow diagram of a process to perform 
user client actions according to the invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

[0032] FIG. 1 relates to a known computer system which 
operates as a sever within the described embodiment of the 
invention. The computer system comprises at least one 
processor 10 which is connected through a data channel 11 
to a system RAM 12 and a memory 14 which may be a hard 
disk storage used to store at least one database of the 
software configuration system according to the invention. 
The computer system further comprises a keyboard and 
mouse unit 15 for the input of data and commands and a 
display unit 16, both connected to the data channel 11. 
Furthermore, the system comprises a network communica- 
tion adapter 17 through which the server may establish a 
data communication to remote computer systems by means 
of a digital communication network 18, such as the Internet. 
The communication adapter 17 also provides data commu- 
nication to at least one client computer fixedly connected to 
the server of FIG. 1, and to other server systems which may 
have a similar design as that one shown in FIG. 1. 

[0033] FIG. 2 shows a simplified block diagram of a 
computer system which may be used to execute an embodi- 
ment of the invention. This computer system comprises a 
first server 20 which corresponds to the server of FIG. 1 and 
which runs a program called Extensible Software Configu- 
ration Markup Language (XSCML) processor 22. The 
server 20 is connected and controls a memory 23 which 
contains, beside other items, a system database 24 storing 
data which is used by the XSCML processor 22. A number 
of workstations 25 are connected to the server 20 through its 
network adapter 17, not shown in FIG. 2. The workstations 
25 operate as clients of the server 20 and have access to the 
database 24 in the memory 23 through control of the 
XSCML processor 22. The computer system of FIG. 2 
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further comprises a set of second servers 27 which are 
connected to the first server 20 to exchange data with the 
first server 20 and to perform access to the database 24 in its 
memory 14 through control of the XSCML processor 22. 
The second servers 27 (herein also called build servers) are, 
in their design, similar to the first server 20 and run compiler 
or build programs installed in the memories 14 of each of the 
servers 27. Such a build server may itself have one or more 
connections to a LAN data server through a communication 
adapter 17 as shown in FIG. 1 for accessing tools and data. 

[0034] A number of computer systems, each one corre- 
sponding to the computer system of FIG. 2, may be dis- 
tributed and connected via a digital communication network 
such as the Internet. FIG. 3 shows three such computer 
systems 30, 31, 32 connected through a communication 
network 34. There may be far distances between the systems 
30, 31, 32. For example, system 30 may be installed in 
Germany, system 31 in India and system 32 in the USA. 

[0035] A system and method according to the invention 
serves to develop and test complex software products, each 
comprising a plurality of software components herein called 
software elements which may form different versions of the 
same software product. Due to the volume and complexity 
of the product, the software elements have to be developed 
and tested by a group of developers and separately compiled 
and linked together to build a package which on its highest 
level represents the software product. The software product 
and its elements are the subject of continuous updates and 
further developments with the effect that there always exist 
different versions of the same software product and its 
elements and that at a certain point of time a new version 
will replace a currently used version of the software product. 
The development, test and updating of a program product 
performed in parallel by different people is designated as a 
project. The invention provides a method and system which 
allow to manage a project effectively, even if the develop- 
ment, test and updates of the software product elements are 
carried out at the same time under different environments at 
different places which have large distances from each other. 

[0036] A central component of the system according to the 
invention is the XSCML processor 22 which administrates 
the software elements, its various versions and relationships, 
and controls accesses to the database and the processes and 
tools available to the system. FIG. 4A shows the compo- 
nents of the system which are controlled or used by the 
XSCML processor 22. A part of the components are data 
sections 41-45 which are included in the database 24. These 
components comprise sets of project meta data 41 which 
include data representing the state of the various software 
elements and their relations among each other. Further 
components are a plurality of product elements section 42 
containing software delta elements documenting changes to 
elements under development or the subject of update opera- 
tions. A product and package definitions section 43 is 
assigned to a plurality of product elements which may 
belong to different product versions. An example of product 
element definitions is described below. A set of input ele- 
ments 44 and generated elements 45 are linked to the 
package definition block section 43. The XSCML processor 
22 has further available project definition data 40 which 
comprises data flow definitions, process definitions and 
process flow definitions. Another component of the system 
is a set of dialog or command line interfaces 46 which are 
used by the XSCML processor 22 as user interfaces or 
command application interfaces and which are distributed to 
the client workstations 25. The XSCML processor 22 may 



establish a connection to the build servers 27 which is able 
to run one of a number of compilers installed on server 27 
or stored on a tool server 50. The XSCML processor 22, the 
client workstations 25 and the build server 27 each have a set 
of tools 48, 49 and 50 available for performing the activated 
processing steps. The XSCML processor 22 may also be 
connected, for example, via a communication network to 
another XSCML processor 52 running on another server 51 
at a remote location to allow team cooperation in the 
development, test and updating of software projects as will 
be explained in connection with FIGS. 3 and 10. 

[0037] The database 24 stored in the memory 23 and 
containing the components 40-45 forms the library system 
of the XSCML processor 22 which provides a descriptive set 
of definitions in an Extensible System Configuration 
Markup Language (XSCML). This language allows to be 
used for generating common definitions of all components 
contained in the library system and is used by the servers 20, 
51, 27 and the clients 25. The XSCML processor 22 per- 
forms the access to the components 40-45 and the underly- 
ing mapping of these components to the library system. It 
also calls the available processes applied to the product 
elements stored in the library system. The XSCML proces- 
sor 22 identifies the product elements themselves and their 
relations to each other in terms of inputs, outputs and logical 
dependencies and specific parameters of the software pack- 
ages to be handled, such as applications, fixes, or work 
elements. Furthermore, the common definitions provided by 
the XSCML processor 22 are also used for the description of 
the access rules for data and processes, the process work- 
flow, the problem reporting, the notification rules, the pro- 
motion rules, build rules and the edit rules. 

[0038] FIG. 4B shows the communication between the 
main components of the system according to FIG. 4A. 
XSCML processor 22 which runs on the server 20 is 
connected to at least one client 25, at least one build server 
27 and tools 48. Furthermore, XSCML processor 22 is 
connected to XSCML processor 52 which runs on the server 
51. The communication between the XSCML processor 22 
and the components 25, 27, 48 and 52 takes place by data 
streams in the XSCML format. These data streams comprise 
product elements and packages as well as project definition 
and process definition data, status data and commands such 
as the call command for a selected one of the tools 48, 

[0039] By using the common extensible software configu- 
ration markup language, the XSCML processor 22 is able to 
provide control of the product elements which includes: 
[0040] change control which keeps track of changes 
of the product elements over different versions of the 
product and parallel access of elements by different 
persons; 

[0041] version control which stores and retrieves 
different iterations herein also called delta elements 
42 of the product elements; 

[0042] item management to create, track and manage 
problems and features; 

[0043] process control to define and follow a 
sequence of steps which take an organization 
through the development process in a predefined way 
with defined tasks to the persons involved in that 
process; process control also addresses the data flow 
and progress flow; 

[0044] build management which provides an automa- 
tion of the translation of product elements 44 and 45 
into other forms 45; 
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[0045] packaging to extract data for delivery of the 
product out of the system library and to bring the 
product in a defined format for delivery. 

[0046] The common extensible software configuration 
markup language XSCML is preferably based on the syntax 
of the well-known Extensible Markup Language (XML) for 
several reasons: 

[0047] XSCML allows to use problem oriented syn- 
tax but based on a standard; 

[0048] XSCML includes in its concept the WEB 
integration which means that references to product 
elements could not only be within a database or file 
system but also reference to any element accessible 
through the WEB via a WEB server could be estab- 
lished if needed; 

[0049] there are already a plurality of tools around 
which support the parsing and graphical representa- 
tion of XML implementation and also XML appli- 
cations based using XML syntax like WebDAV 
which can be used in the implementation of an 

* XSCML framework; 

[0050] XSCML is defined as platform independent 
especially if the programming language JAVA will 
be used for the parser and logic; 

[0051] XSCML provides the capability of transfor- 
mation between flavors of different XSCML appli- 
cations; 

[0052] XSCML allows to generate self documenting 
applications which are human readable on the screen 
or as printed materials or to be used for distribution 
or publication by means of the Web. 

[0053] The XSCML does not force the developers to use 
XML for the software development and update work. In 
accordance with the character of XSCML, the content of 
each product element is independent of the configuration 
steps controlled by the XSCML processor 22. Thus, the 
development of the product elements can be performed in 
any native language. Graphic user interfaces may facilitate 
the use of the XSCML defined information. 

[0054] Working with Product Elements 

[0055] As already mentioned, there are two ways to look 
to the environment from a developers perspective. The one 
is to work with files on a file system using an organization 
with directories or looking to a library system to work with. 
Instead of files, an object paradigm may be applicable which 
extends the widely used file system paradigm and wherein 
the files and directories are treated as special objects. For 
simplicity, the file system paradigm will be used in the 
following. In practice, the developers actually work prima- 
rily on a file system base, because they have the most 
flexibility to use different tools. The library view is only 
important to have a save repository to store data so that the 
work results are saved. 

[0056] In practice, the developer works on projects which 
means that for a certain project the developer has a static 
view on the project as long as the project is alive and he is 
interested to have available reproducible data during this 
period. The known methods to perform the development of 
software projects do not solve the relationship and promote 
between the hierarchy of the software elements and the 
developer team development environment. If such approach 
is extended to a team of developers where each developer 



uses a single user based development workframe product, 
each project of a developer is mapped to a directory of data 
memory accessible through a LAN (local area network), for 
example, where common drivers are integrated on a com- 
mon LAN directory. 

[0057] This leads to the structure as shown in FIG. 5 
wherein the team produces in three parallel workframe 
products DEVA, DEVB, DEVC product elements. This 
work is then the subject of a test operation, i.e., in a LAN 
directory TEST, the result of which is the final product, i.e., 
in a LAN directory PROD. Such directories are herein also 
called groups. A basic rule is that only in the bottom groups, 
modification must be done. As shown in FIG. 5, product 
elements can only be moved to PROD 54 from TEST 55, 
and elements can only be moved to TEST 55 from DEVA, 
DEVB or DEVC. Edits can only be done through DEVA, 
DEVB and DEVC. The blocks 54-58 represent data sets 
stored in the database or in the memories 14 of the client 
workstations. 

[0058] Important is that at the same time the same element 
of a product developed in a structure like FIG. 5 can exist 
in different modification instances in all blocks 54 to 58. 

[0059] It is also important to understand the different type 
of groups in such a structure which is described below and 
also shown in the Table 1 : 

[0060] Edit group: These are always the lowest 
groups in a group hierarchy. Creation and changes of 
elements can only be made in such edit groups 
through client programs via XSCML APIs (applica- 
tion programming interfaces) or XML streams. 

[0061] Transition groups: These are groups which 
have one or more lower groups in the tree to receive 
packages. It has just one higher group in the hierar- 
chy to promote packages further on. 

[0062] Target group: These groups are the same as 
the transition groups, but are not allowed to promote 
packages to its higher groups, if available. 

[0063] Baseline groups: These groups are the same as 
the target groups, but the packages are freezed which 
means that no promotions from lower groups and to 
higher groups are possible. In other words, editable 
members in those groups can never be changed. 



TABLE 1 





Number of 
from groups 


group actions to groups 


Edit group 


0 


edit (check-in, check-out) 1 






build, promote, query 


Transition group 


1 to n 


build, promote, query 1 


Target group 


1 to 0 


build, query 0 to 1 


Baseline group 


0 to n 


query 0 to 1 



[0064] With regard to this situation, the invention defines 
software projects by an XML approach. In the following, it 
is assumed that a client obtains project elements or data from 
an XSCML system through an XSCML project definition 
which indicates which files in file system should be pro- 
cessed and which libraries are connected to the directories to 
control the content and the movement of the files within the 
file system. 
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[0065] The project definition contains three major sec- 
tions: 

[0066] Data flow definition: Those tags define the 
logical data representation together with the physical 
data mapping stored in the real product using the 
XSCML processor paradigm. It includes the project, 
group, type, file, element notation. This major sec- 
tion is shown below in Example 1. 

[0067] Process flow definition: Those tags define the 
order of process states intersecting with the data 
flow. Each process state may even trigger some data 
flow activities, like build, promote or create delta 
version of element or packages. This is shown below 
in Example 2. 

[0068] Process definitions: Those tags define the 
actions steps associated to elements for user actions 
as edit, build, promote. This is shown in Examples 7 
and 8. 

[0069] Files are always in an XSCML protected mode 
dependent on the file system capability which is at least a 
read only attribute. Updates are only done through an 
XSCML processor triggered by the client. The library sys- 
tem implementing an XSCML processor may hold a com- 
plete copy of the current product version as in the file system 
for recovery reasons. This copy is not seen by the client who 
has the perception that he is working with an underlying file 
system. To hide the client from different possible file map- 
ping, a logical naming concept is provided to work with. In 
a simple project, the logical to physical mapping could be a 
one to one mapping. This concept may be as follows: 

[0070] Project: This is an undertaking with pre- 
scribed objectives, magnitude and duration. A 
project may be the development of a software prod- 
uct or an update of an existing software product. For 
a project, the client may know, through a defined 
mapping, the root directory he is working with. 

[0071] Group: A set of project data sets of the ele- 
ment hierarchy. The client may know via the defined 
mapping the sub directory following the root direc- 
tory which is ideally the same as the group name. A 
group defines an active version of defined quality of 
a product. 

[0072] Type: A type categorizes elements of a project 
like modules, macros, object code, listings and load 
modules. The client may know, via the defined 
mapping from logical to physical name, the exten- 
sion of file belonging to a Type or the directory name 
of a Type. 



[0074] Element : The atomic unit to be managed by an 
XSCML system. It could be a one to one relation 
between element and member where an element is 
the same as a member. The scope of an element is 
defined by the development language, products and 
tools used in an XSCML system. An element has an 
XSCML language assigned. 

[0075] Language: This is a process definition defined 
in XSCML syntax which describes the tools invoked 
at certain XSCML actions triggered by the clients 
and related to packages, members or elements. 

[0076] Besides the data definition actions, a set of actions 
is available to establish the XSCML framework and to apply 
that action to the data assigned to XSCML framework by the 
project definition. 

[0077] Such actions are at least: 

[0078] Edit: Edit actions apply if the user creates or 
changes the content of an element in the XSCML 
system. A predefined action of Edit is normally a 
parse for dependencies or for other statistical infor- 
mation of the source code, or for synchronization of 
update actions to elements. This action is either 
invoked by an editor used by the developers or 
corresponds to the action check-out to lock a mem- 
ber for edit and check-in to bring the changed 
member back to the XSCML system. 

[0079] Build: Build actions apply if the user issues 
the build function against a package which itself may 
contain other packages. The XSCML system will 
then invoke, for each referenced element in the 
package hierarchy, the predefined actions defined by 
the language in the process definitions. The pre- 
defined action of Build covers all steps to transform 
one or more source code elements to one or more 
output elements. 

[0080] Promote: Promote actions apply if the user 
issues the promote action against a package which 
itself may contain other packages. The XSCML 
system then moves all elements related to a success- 
fully built package or referenced packages in a 
package hierarchy up to the next higher group 
defined in the XSCLM system. 

[0081] The actions are described later with reference to 
FIG. 14. The actions themselves are defined in XSCML 
syntax to be passed to the XSCML processor for execution. 
Such definitions may, for example, read as follows: 



<EDIT PROJECr- M PRODUCTA" w GROUP=DEVA" FILE="HELL0.CPP7> 
<BUILD PROJECr^PRODUCTA'* "OROUP=DEVTA" TYPE= U CPP _PKG" 

HLE--HELLO" MODE»"NORMAL7> 
<PROMOTE PROJECTVPRODUCTA" "GROUP-DEVTA" TYPE-"CPP_FKG W 

FTLE="HELLO" MODE-"UNCONDITIONAL"/> 



[0073] Member: This identifies a data set or product 
element, or contains several elements and serves as 
its symbolic address. It is the atomic item managed 
by the file system of an underlying operating system. 
A member has an XSCML language assigned. 



[0082] The actions are common across the underlying 
implementing products of the XSCML framework. Thus, the 
mapping to the real commands are provided through the 
project definitions as shown in Example 1 in the section 
where the database related definitions are specified. Such 
mapping may, for example, take place as follows: 
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<DB> 
<Mapping> 

<ACTION_MAP ACTIO EDIT" GROUP-" TYPE^-> 

<CMD>LPEX </CMD> 

<PARMS>##FILE##.... </PARMS> 
</ACTTON_MAP> 

<ACTION_MAP ACTIO BUILD** GROUP--" TYPE=*"*"> 
<PARM_MAP KEY="MODE" 

NORMAL C 

C C 

FORCED F 

REPORT R 
</PARM_MAP> 

<CMD>FLMCMD BUILD, </CMD> 
<PARMS>^roject^,##group##,##typc##,##file##, } , 

##MODE##,... 

</PARMS> 
</ACTION_MAP> 

<MAPPING> 

<DB> 



[0083] Based on such definitions, a build command issued 
my be mapped to "FLMCMD BUILD,PRODUCTA, 
DEVTA,CPP_PKG ,HELLO,„C . . . 

[0084] If a file gets created, the logical elements: "project, 
""group /'"type" and "element" must be specified. The 
physical names are then dropped by the project definitions. 

[0085] An XSCML element is identified by a dot notation 
like "name .ext" where "name" relates to the element name 
itself and "ext" specifies the implicit container where the 
element may exist. The container may be explicitly defined 
in more detail by using an extra type definition. So <SINC 
TYPE="src">helLo.cpp will define an element "hello" in a 
container named "src". In the mapping rules, the use of "ext" 
and "TYPE-" is specified. 

[0086] For files to be managed on a workstation, if no 
complicated mapping is needed, the logical view leads 
directly to the physical view of: 



[0087] &root;\##project##W#group##\##member## 
.##typc##. 

[0088] For datasets on a OS/390 system, the logical view 
leads directly to the physical view of: 

[0089] 

##project##.##group##.##type##(##member##) 

[0090] For the granularity of elements, a type dependent 
mapping is available which is dependent on the editor to be 
used to manipulate such elements stored in the unit of a 
member. 

[0091] This is the preferable approach because it is intui- 
tive to the developers. If the update is done through the 
XSCML client, then the root could even be a local fix disk 
storage of the developers if customized in the project There 
are options of using the groups. The contents of the groups 
may contain only the needed differences along the hierarchy 
or the groups may contain a fill copy of the packages the 
developer is working on. In the last case, the developer is 
able to work standalone and synchronize with the underlying 
file system in the database if the client is online again. 
However, this requires more logic for reconciliation or 
replication. 

[0092] According to the invention, even if a different 
mapping of logical and physical names is done for elements, 
they are always presented to the user under the terms 
"project,"" group,"" type" and "element." This is shown in 
the subsequent Example 1 which relates to an XSCML 
system of a software product the name of which is "My 
Product" and includes those definitions of the XSCML 
which are used to define the XSCML system. The first part 
of the example shows the data flow syntax followed by a 
mapping of the logical types, and thereafter the mapping of 
the product elements to the physical memory. It follows the 
process flow and finally the language definition or so-called 
process definition. The examples are self-documenting and 
are based on FIG. 10: 

EXAMPLE 1 

Editing of the Software Product "My Product" 
[0093] 



<!DOCTYPE PROJECT | 

<!~ Physical file directories to be used --> 

<! ENTITY root "\\producta\rcll"> 

<! ENTITY tester "\\test\pioductaVielP*> 

<! ENTITY product *producta"> 

]> 

<PROJECT NAME-" MY Products 

<!-- It follows the group hierarchy definition which is the 
logical view on a physical directory structure. The physical 
mapping is described later. In the s imprest way, the group 
name is a subdirectory to a root directory, where the 
root directory is common to all groups and relates to a 
project. -> 

<GROUP NAME-TROD" DB-TRODLIB" ACVREL" FILEMAP-"M0"/> 
<GROUP NAME-TEST' DB-TESTUB" AO"REL" PROMOTE-TROD" 
FILEMAP-"M17> 

<GROUP NAME-TJEV1" DB-"DEVUB" AO"REL,TEST" PROMOTE-TEST" 
FILEMAP-"M27> 

cGROUP NAME--DEV2" DB*»**DEVLIB" AO"REL" PROMOTE-TEST" 
FILEMAP-"M27> 

<GROUP NAME-TEAMT* DB=**DEVUB" AO**REL,TEST" PROMOTE-TEST' 
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-continued 



FILEMAP="M37> 

<GROUP NAME="TEAM" DB»"DEVLIB" AO"REL,TEST" PROMOTE="TEAMT" 

FTLEMAP="M37> 
<!- It follows now the logical types known to the project, 
which have a physical mapping dependent on the 
environment the source exists.- > 
<TYPE NAME="CPP"> 

<!- There may be additional tags for some more detailed 
mapping or specifications to a physical representation --> 
</TYPE> 

<TYPE NAME="HPP"></TYPE> 

<TYPE NAME-"H"></TYFE> 

<TYFE NAMEo"OBr'></TYPE> 

<TYPE NAMEo"LST'></TYPE> 

<TYPE NAME« 4 'EXE"></ryPE> 

<TYPE NAME="DLL"></TYPE> 

<TYPE NAME-"CPP"4ink></TYPE> 

<!- It follows the association which database and elements 

in the database does manage the group contents with regard 

to state and content. If several databases would be 

possible, there must be a synchronization done between those 

databases defined by this project definition. Farts managed 

in such a way may only be modified through such a project 

definition and not by using the database interfaces 

directly. Only a read access to such elements through the 

database interface may be allowed. --> 

<DB NAME-"PRODLIB"> 

<!— Here comes some more specific information where to 

find the related database system like TC Family, SCLM 

project, etc., to hold the data or meta data to control the 

content of the file system described by the project. It 

may define also the degree of versioning done in the 

database, i.e., for groups and types or association of 

groups to processes or states. Also, logical to physical 

mapping is defined here —> 

<MAPPING> 

<ACTION_MAP...> , 

<ACTTON_MAP...> 

</MAPPING> 
<FILEMAP NAME« M M0"> 

<!-- Here comes the detail mapping how files should be 
realized on file system based on the logical access using 
the group and type specification. It is assumed that a 
string like ##var## are variables defined through the XML 
syntax. Like ##group## maps to the value of GROUP 
parameter of the <groupmap ...> tag 
--> 

&root;\##gioup##V#^ember##.##ext## 
</FILEMAP> 
</DB> 

<DB NAM E="TESTLI B"> 
<MAPPING> 

<ROOTMAP RLE _ROOT-"\\product\product\7> 
<GROUPMAP GROUP-"*" FILE_GROUP-"*Y7> 
<GROUPMAP GROUP-"PRODr FlLE_GROUP-"productionV7> 
<TYPEMAP TYPE-"c_Jype" FILE_TYPE-"src\cpp" 
FILE_EXT-"cpp7> 

<TYPEMAP TYPE-"*" USE_EXT-"EXT7> 
</MAPPING> 
<FILEMAP NAME-"M1" > 

&tester,\^(mp##\##name##.##ext## 
</FTLEMAP> 
</DB> 

<DB NAME="DEVUB'*> 
<MAPPING> 

<ROOTMAP FILE_ROOT="PRODUCI77> 
<GROUPMAP GROUP-"*" FTLE_GROUP- M *."/> 
<GROUPMAP GROUP-"PRODl" FILE_GROUP="PRODUCTl\7> 
<TYPEMAP TYPE="cpp_type" RLE_TYPE="SRC" 
FILE_EXT="CPP'7> 
<MAPPING> 

<FILEMAP NAME="M2"> 
##root##.##group##.##typ e##$##ex t##(##name##) 
</FILEMAP> 
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-coatinued 



cFILEMAP NAME- M M3"> 

</FILEMAP> 
</DB> 

<PROCESSFLOW> 

</PROCESSFLOW> 

<!-- Here comes now the process definitions so-called 
languages which will be discussed later 

--> 

LANG...> 
</LANG> 

<LANG „>...</LANG> 
<ACCESS> 

</ACCESS> 
</PROJECT> 



[0094] As an alternative to the definition of the data flow, 
the hierarchy of the product elements may be defined by a 
work flowtree. This is shown in the subsequent Example 2 
wherein two users and one team are cooperating in the 
development and testing of a software product which results 
from the flowtree which comprises the following flow 
groups. The example relates to FIG. 6. 

EXAMPLE 2 



XSCML Syntax for the Dataflow Defined as Flow 
Tree: 

[0095] 



<DOCTYPE FLOWTREE []> 
<!— The data flow hierarchy — > 
<FLOWTREE> 

<FLOW LEVEL-TROD1" ACCV*P17> 
<FLOWGROUP> 

<FLOW LEVELVFDCPRODl" ACC-"T'/> 
<FLOW LE VEL-TIXTESTl " ACCVT7> 
</FLOWGROUP> 
<FLOWGROUP> 

<FLOW LEVEL-TROD2" ACO"R'7> 
<FLOW LEVEL-"STEST2" ACC- U R7> 
<FLOW LEVEL- M FTEST2" ACC-"R7> 
<FLOWGROUP> 

<FLOW LEVEL="DEVAT' ACO"R,TV> 
<FLOW LEVEL="DEVA" ACC=* , R,T'/> 
</FLOWGROUP> 
<FLOWGROUP> 

<FLOW LEVEL- M DEVTB" ACO"RT7> 
<FLOW LEVEL« M DEVB" ACC="R,TV> 
</FLOWGROUP> 
<FLOWGROUP> 

<FLOW LEVEL-TEAMT' ACC-* 4 R ( T , /> 
<FLOW LEVEL-TEAM" ACO"R,T7> 
</FLOWGROUP> 
</FLOWGROUP> 
</FLOWTR£E> 



[0096] Software Elements and Packages 

[0097] It is required to define a package with regard to its 
input and output and which parameters can be passed to the 
different processes needed to proceed from the input(s) to 



the output(s), also called generated elements. A package 
definition can be implicitly defined through an element by 
means of the process definition associated to an element. 

[0098] Package: 

[0099] A package may be treated as an element in the 
database and defined via tags which describe the explicit 
relation between input elements and generated elements. 
The tags also define the process definition associated to treat 
the input element and generate the elements from input 
elements. They may further define package parameters 
which are passed to the associated process steps in the 
process definitions. Some of the package definitions may be 
defaulted through the project definitions or meta data asso- 
ciated to elements referred to in the package. This means that 
an input element may be an implicit package definition if the 
associated process definition contains all the package defi- 
nitions as default values, such as types for generated ele- 
ments, explicit dependencies, parameters to process steps, 
etc. A package may refer to other packages as dependent 
packages to be processed before the referring package. 

[0100] The fact that packages may refer to other packages 
results in a build tree and promote tree of such packages. A 
build tree of this type can define the complete product to be 
processed through one build action, and it shows the depen- 
dencies between packages and elements. 

[0101] Besides the explicit dependencies between ele- 
ments defined through packages, there are implicit depen- 
dencies which are found by the XSCML defined processes 
either after a save of editable elements or after a build of an 
element. To determine such implicit dependencies, the pro- 
cess definition defines the invocation of the tools to find and 
store the dependency information. 

[0102] To enable the users to define the build steps, they 
must be able, besides denning the package content, to define 
several builders as one unit and define the information for 
creating the packages to be handled in one unit. The users 
are able to create such a unit through a textual representation 
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which could then be used for a graphical representatioa In 
addition, the creating step may be supported through a 
graphical user interface 

[0103] TTie method provided by the invention to define 
build steps and packages reduces the complexity of the build 
tree to a minimum. The packages are the only nodes in the 
build tree. One package however may be represented 
through expansion as a number of separate trees to show the 
input, outputs and include hierarchy. Common parameters 
(e.g., compile options, common includes) can be hold as 
separate elements and included through the XSCML syntax 
into different packages. Furthermore, reusing of defined 
builders for different projects becomes simple, because it is 
possible to create builders with more flexibility (e.g., file 
extensions does not have to be specified in the builders). 



[0109] 2. Link packages for link transformations, called 
(L) packages. Link packages may refer to (C) or (L) 
packages. 

[0U0] 3. High-level packages describing applications 
and sub-applications, called (HL) packages. High-level 
packages may refer to (Q, (L) or (HL) packages. 

[0111] 4. Include packages to share common informa- 
tion across packages, called (I) packages. Include pack- 
ages may be part of (C), (L), (HL) or (I) packages. 

EXAMPLE 3 

Use of the Compile Package hello.cpkg to Compile 
the Source Code hello.c: 

[0112] 



<!DOCTYPE CPKG{<! ENTTTY parmsetl "<PARM1> /Fo+ <PARM1>">> 

<!— The (C) package unit which defines input and outputs elements and processing 

parameters -> 

<CPKO NAME» w helio" TYPE= w cpp_compile"> 

<!-- LANG="CPP" defines parser and the set of builder steps 
to be used for the related input member when actions such 
as build against it will occur. If omitted than the 
language associated to the input member will be used 
instead. --> 

<LANG NAME="CPP" /> 

<!-- The input member to be processed --> 

<SINC type="CPP_J^T > >hello.cpp</SrNC> 

<!-- The output members to be produced by the defined 

builder steps in the language --> 

<OBJ>heIlo.obj </OBT> 

<UST>hello.lst</LIST> 

<!-- The parameters to be passed to the different builder 
steps defined in the language -> 
<PARM1>/L+ /Ti+ </PARMI> 
&parmsetl ; 
«/CPKG> 



[0104] Builders with more than one build step can be 
implemented through the XSCML language with several 
build steps as shown in the following examples. The mul- 
tiple step processes are defined through one build script. No 
programming skill (REXX, C++, JAVA, PEARL) is neces- 
sary to implement such process integration. 

[0105] BUILD Action Against Packages 

[0106] The IBM publication "TeamConnection Users 
Guide," publication no. SC34-4499-04, page 183, FIG. 58, 
contains a sample build object model for msgcatexe. Ref- 
erence is made to this example for the subsequent descrip- 
tion of the XML based definitions for the build function and 
the package definition of three types of packages. In this 
description Examples 2, 3 and 4 are represented which are 
related to the build of a package by the compilation of two 
elements with a subsequent link operation. These examples 
include the definition of the work units and packages as used 
for the compilation steps of two elements where the results 
of which are linked to a high level package. 

[0107] We distinguish between: 

[0108] 1. Compile packages for compile transforma- 
tions, called (Q packages. 



EXAMPLE 4 

Use of the Compile Package bye.cpkg to Compile 
the Source Code bye.c: 

[0113] 



<IDOCTYPE CPKG{ 

<!ENTTTY pannsetl M <PARMl>/Fo+ <PARM1>"> 
> 

<CPKG NAME="bye" TYPE-"cpp_compile"> 

<LANG NAME-"CPP" /> 

cSINC type-"CPP_J^T'>bye.cpp<ySINC> 

<OBJ>bye.obj </OBJ> 

<UST>bye.lst</UST> 

<PARM1>/L+ /Ti+ </PARMl> 

&parmsetl; 
</CPKG> 



[0114] The code compiled in the examples 3 and 4 arc 
linked to create a package. This is shown by Example 5. 
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EXAMPLES 

Link Package msgcaUpkg to Create Package 
msgcat.exe: 

[0115] 



[0119] Process Definitions — Collection of Predefined 
Actions Applied to Packages 

[0120] The XSCML project definitions contain any pre- 
defined action which a user can apply to packages. Such 
actions comprise Edit, Build and promote like actions to 



<!DOCTYPE LPKGi<IENTTTY pannsctl "">> 

<!- The package unit which defines input and outputs -> 

<LPKG NAME-"msgcat" TYPE-"cpp_link"> 

<l-- LA NG- U LINIC ' refers to the set of builders to be used for the related input 
member when actions such as build against it will occur. If omitted a default language 
will be assumed, such as "link", to be defined to TC via a language definition defined 
below. --> 

<LANG NAME-"LINK"> 

<!— Creates references to input member to be processed based on keywords in the 
referenced entities --> 

<KEY REFS-"OBJ LOAD7> 

<!-- References to the compile packages to generate a response file in the language 
link --> 

<INCL NAME=*hello" TYPE-* , cpp_compac7> 
<INCL NAME»"bye" TYPE-"cpp_compilc"/> 
cCMD> input command statements to the linker </CMD> 
<CMD> input command statements to the linker </CMD> 
cALIAS> msgalias </ALIAS> 

<!-- The output members to be produced by the defined builder steps in the language 

--> 

<LOAD>msgcat.exe</LOAD> 
<LIST> ms gcat. map </U ST> 

<!-- Here are currently no parameters to be passed to the different builder steps 
defined in the language -> 
<PARM1> </PARMl> 

&parmsetl; 
</LPKG> 



[0116] In the following Example 6, the definitions for the 
whole application by using a high level packaging are 
described. 

EXAMPLE 6 

Using High Level Package Prodi. hpkg for 
Describing the Whole Application msgcat 

[0117] 



<!DOCTYPE HPKGf 
]> 

<!-- The package unit which defines input and outputs --> 

<HPKG NAME-" PRODI" TYPE="app"> 
<!— References to the link packages — > 
<L\ T CL NAME-"appl" TYPE-"app'7> 
<LS T CL NAME-" msgcat" TYPE-* i cpp_link*7> 
<INCL NAME-"gui" TYPE-"gui_compi]e'7> 

</HPKG> 



[0118] So far, we defined the package contents through 
XML based definitions. However, the package also refers 
explicitly to the languages being used for each package 
which contain the related predefined actions to be performed 
in detail when a user works with the package during an edit, 
build or promotion to a higher development stage. A pre- 
defined action for an edit may be parsing for dependencies, 
and for a build, the different build steps to transform the 
inputs) into the output. 



bring the package from one integration state to another. The 
most basic actions the user may apply are Edit and Build. 

[0121] The predefined action of Edit is a parse for depen- 
dencies or for other statistical information of the source 
code, or for synchronization of actions. The predefined 
action of Build covers all steps to transform one or more 
source code elements to one or more output elements. 

[0122] In the examples considered herein, two processes 
are used. One process is used to do the C++ compile and the 
other to do the LINK. Both processes contain only one build 
step. 

[0123] If more build steps are needed to get the build 
outputs, several steps of TYPE-" BUILD" have to be 
described. In this case, the generated outputs from the first 
step have to be indicated as input to the next step. An 
example of such case, which is typically for an OS/390 
build, is shown below. 

[0124] To allow a specific treatment of files especially in 
a language with several process steps, different IOTYPE 
keywords are defined for the inputs and outputs. Such 
information is then used by the builders to allow the special 
treatment of the associate files: 

[0125] IOTYPE-S: Used for input data that is speci- 
fied with a <SINC . . . >tag. It means the files or data 
sets do exist and must not be created by the builder. 

[0126] IOTYPE-I: Used as an allocation information 
to get access to additional files needed during the 
associated process defined in a <SCRIPT . . . >tag. 
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[0127] I07YPE=0: Used for output data that is 
specified with tags like to <OBJ . . . >, <UST . . . >, 
<LOAD . . . >, <OUTx . . . >. Data sets or files are 
created during the build. The output is stored in the 
element storage of the system after a successful 
build. 

[0128] IOTYPEoW: Used for work data set needed 
for temporary use in one step or even succeeding 
steps in multistep processes. Ilie output is, however, 
not stored after a successful build. 



[0130] IOTYPE=A: Used for data sets or files which 
do already exist and are referred to from the build 
steps. Tbey are normally not created by a related 
process during a process step and may contain or not 
contain information stored in the element storage of 
the system. 

[0131] Other IOTYPE keywords may be defined. 

[0132] The related process c-comp.lang for the language 
C++ can be defined as follows: 

EXAMPLE 7 



[0129] IOTYPE-N: Used in an OS/390 language to 
define a dummy entry & 0{f or a ddname list to be 
passed to the program called. [0133] 



<CLANG NAME»"C" env-"NT' Version_id-' , 3.6.0"> 
INCLUDES ID="hflles"> 
<!— steps active during the parse of parts — > 

<!-- UB« M YES": IT: am Connection controlled header files, identified by a TYPE 
attribute provided for --> 

<l~ LJIWNO" system header files, not controlled by TeamConnection~> 

<INCLUDE PATH-"src/include" UB-"YES" 
TYPE-"h__inc" /> 

<INCLUDE PATH-^src/package" LIB-"YES" 
TYPE-"h_pkg» /> 

<INCLUDE PATH-"." LIB-"YES" TYPE-"h" /> 

<INCLUDE PXTH-"sys/c" UB-"NO" /> 
</INCLUDES> 
<STEP TYPE-"PARSE"> 

<SCRIFT name="parse_c7> 

<PARMS> -SOURCE ##source## -IDRS ##INCLS## -DEPFTLE 
##deps##^PARMS> 

<FILE ID-"source" KEYREF="SINC" /> 
<FILE ID- M incls" REFH> M oii]es" /> 
<FILE ID-"deps" NAME=**csource.deps" /> 
</STEP> 

<!-- steps active during the build of parts -> 
<STEPTYPE-"BUILD'*> 
<SCRIPT name="icc'7> 

<PARMS K£YREF-"PARMl">/Fo:##objecte##/Fl:##listing## fl ##includes## 
##input##</PARMS> 

<RC cond="<=" vaI="4"/> 
<!-- PRENT=YES indicates that the output should 
also go to the build message even when build 
fails --> 

<FILE ID-"in P ut" KEYREF-"SINC" IOTYPE-"S7> 
<FILE ID-"object" K£YREF-"OBJ" I0TYPE-"07> 
<FILE I Delisting" KEYREF-"USTT' tOTYPE-"0" PRINT-"YES7> 
<FILE ID- W includes" KREYREF-" INCL" 
REFID-"hfiles'7> 
^STEP> 
</CLANG> 
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[0134] The related process c_link.lang for the language 
LINK can be defined as follows: 

EXAMPLE 8 

[0135] 



<LLANG NAME-" LINK" env-"NT" Vcreion_id-"3.6.0"> 
<!-- steps active during the build of parte — > 
<STEP TYPE- < -BUILD"> 
<SCRIPT namc-"ilink'7> 

<PARMS KEYREF-"PARM1"> /OUT.##out## /MAP:##mapW 
objects -tfEARMS> 

<RC cond»"<»" val» M 4"/> 

<!-list of input and output files— > 

<FTLE ID="objects" KEYREF="INCL" IOTYPE-"S7> 

<FTLE ID=-our KEYREF-"LOAD" I0TYPE-"07> 

<FILE ID="map" KEYREF=" LI ST ' IOTYPE"07> 

</STEP> 
<JLASG> 



[0136] The examples are not exhaustive but are provided 
to disclose the principles to specify a complete build which 
enables a user to generate parsers and builders which contain 
no environment specific information but get all passed via 
parameters or environment variables based on the XSCML 
definitions and meta data stored in the XSCML memory. 

[0137] Process Definitions for a Package with a Multistep 
Language 

[0138] The following example shows how more complex 
languages are implemented with XSCML. The example is 
based on a OS/390 Transformation with the following build 

steps: 

[0139] 1. CICS preprocessor to translate the EXEC 
CICS statements into C++ procedure calls. 

[0140] 2. C++ compiler is called to do the real compile 
to create the object. 

[0141] 3. The final step collects all the listings produced 
before from CICS and C++ into one listing which is 
stored as one entity. 



[0142] The central definition of the compile parameters 
can be extracted from the compile package, stored in an 
additional part of the database and referenced in the compile 
package: 



acs.panns 

<PARM1> MAR(1,80) OM(1,80) </PARMl> 
c370.parms 

<PARM2> LIST AGGREGATE </PAKM2> 



[0143] The compile package cicspart.pkg is used to build 
cicspart.mod: 

EXAMPLE 9 

[0144] 



<!DOCTYPE CPKG [ 

<! ENTITY cicspanns SYSTEM "cics.panns"> 
<! ENTITY c370parms SYSTEM M c370.parms"> 
]> 

<!— The package unit which defines input and outputs — > 
<CPKG NAME-"cicspart" TTPE="c390cics M > 

<CLANG NAME-"c390cics"> 

<OBJ>cicspart.obj </OBJ> 

<UST>cicspartlst370</LI5T> 

<OUTl>ticspartlstcics</OlJn > 

<OUT2>cic5partlst<^OUT2> 

<!-- The parameters to be passed to the different 

builder steps defined in the language — > 

<PARMl>NOS NSEQ </PARMl> 

&cicspaims; 

<PARM2> SOURCE RENT LONG NAME SHOWINC NOSEQUENCE 
</PARM2> 

&c370parms; 
</CPKG> 



03/15/2004, EAST Version: 1.4.1 



US 2002/0040469 Al 



13 



Apr. 4, 2002 



[0145] The related Language cics370 Jang can be defined 
in a general fashion using variables in their definition. By 
providing a variable definition, member languages may be 
created from reusable parts in a plug together fashion. 

[0146] The language is then a collection of predefined 
building 

EXAMPLE 10 

[0147] 



<!DOCTYFE LANGf 

<! ENTITY includes SYSTEM * > c_includc.libs"> 

<! ENTITY parsec SYSTEM **parse_c.step"> 

<|— parameters for ctcs preprocessor step building block — > 

<! ENTITY IOTYPE_SYSIN "S"> 

<! ENTITY DD_SYSIN "CICIN"> 

<! ENTITY KEYREF_SYS[N M SINC> 

<! ENTITY DD_SYSPR1NT "CICPRINT"> 

<! ENTITY KEYREF_SYSPRINT'"> 

<1 ENTITY RECFM_SYSPRINT "VBA"> 

<!ENTTTY LRECL_SYSPRINT "137"> 

<! ENTITY RECNUM_SYSPRINT "35000"> 

<! ENTITY KEYREF_SYS PUNCH «"> 

<!ENTITY DD_SYSPUNCH "CICPUNCH"> 

<! ENTITY RECFM_SYSPUNCH "FB"> 

<! ENTITY LRECL_SYSPUNCH "80"> 

<l ENTITY RECNUM_SYSPUNCH w 80000"> 

<ENTTTY cicspre SYSTEM "cics.step"> 

<!- parameters for cics compile step building block --> 

<! ENTITY DD_COMPUNCH "&ddL_syspundi;"> 

<! ENTITY DD_ALL "DD__ALL"> 

<!ENTTTY c370comp SYSTEM "c370.step"> 

<I- parameters for listing joiner building block --> 

<! ENTITY DD_Jst_cpre "&dd_6ysprint;"> 

<!ENTTTY DD_lst_comp M &dd_all"> 

<! ENTITY packlst SYSTEM "packlst.step"> 

]> 

<LANG NAME-"c370cics" env- M MVS" Version_id-"3.3.0"> 
<!-- include library chain used in the language in different steps — > 
^includes; 

<!-- steps active during the parse of parts related to a 
package --> 
&paiseq 

<!-- steps active during the build of package -> 



-continued 

&cicspre; 
&c370comp; 
ftpacklst; 
</LANG> 



[0148] Central building blocks like parser and build steps 
provided by a central build team can be reused to create 
several languages which just differ in the number of steps or 
different parameters. 

[0149] The include building block is c_include.libs: 
EXAMPLE U 

[0150] 



INCLUDES ID-"hfiles"> 

<INCLUDE UB-"YES" TYPE- M H"/> 
<INCLUDE UB- U YES" TYPE-"H_P"/> 
<INCLUDE LIB -"YES" TYPE- M H_USER7> 
<INCLUDE PATH-"SYSl.aCS.SDFHC370" UB-"NO" /> 
<INCLUDE PATH-"SYS 1 . CICS .SDFHM AC" LIB-"NO" /> 

</INCLUDES> 



[0151] A parsing step building block is parse c.step: 
EXAMPLE 12 

[0152] 



<STEP TYPE«*PARSE"> 

<SCRIPT NAME-."parse_c7> 

<PARMS> -SOURCE ##source## -IDIRS ##inck## -DEPFILE 
##deps##</PARMS> 

<F1LE ID-"source" KEYREF- U SINC" IOTYPE- M S" /> 
<FILE ID-"incls" REFTD-"h files" IOTYPE-"!" /> 
<FILE ID-"deps" NAME-"csource.deps" IOTYPE-"W" /> 

</STEP> 



[0153] The CICS preprocessor step building block defi- 
nition is cics.step: 

EXAMPLE 13 

[0154] 



<! - CICS Pre compile --> 
<STEP TYPE-"BUILD"> 

<SCRIPT CALLENV= M ATTACHPGM*' NAME*»**DFHEDP$" 
DDUST-n > YES7> 

<PARMS PARM KWD=" PARM 1 "></PARMS > 

<RC COND- M <»"vaU ,4 4'7> 

<DD IOTYPE-'N"> </DD> 

<DD IOTYPE-"N M > </DD> 

<DD IOTYPE="N"> </DD> 

<DD IOTYPE--Nr> <^DD> 

<!«SYSIN Input to be compiled -> 

<DD IOTPYE=-&IOTYPE_SYSIN." DDNAME-"&DD_SYSIN." 
KEYREF--&KEYREF_SYSIN."></DD> 

<!-- SYSPRINT Listing from the precompile --> 

<DD I0TYPE--O" D DN AM E- w &D D_SYS PRINT. " 
KEYREF- a &KEYREF_SYSPRINT" RECFM-"&RECFM_SYSPRINT." 
LRECL-"&LRBCL_SYSPRINT." RECNUM-"&RECNUM_SYSPRINT."> </DD> 

<!-- SYSPUNCH -> 

<DD I0TYPE-"O" DDNAME«"&DD_SYSPUNCH.'* 
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-continued 



KEYREF-" & KEYREF_SYSP UNCH." 

RECFM-"& RECFM_SYSPUNCH." LRECL»-&LRECL_SYSPUNCR" 
RECNUM«"RECNUM_SySPUNCH"></DD> 
</STEP> 



[0155] The C compile step building block is c370.step: 
EXAMPLE 14 

[0156] 



completed and shipped to customers. Errors which are found 
after the shipment are fixed and the subject of a test 
FIXTEST1 and followed by an integration into corrected 
product FIXPROD1. 



<]-- C Compile --> 
<STEP TYPE="BUILD"> 

<SCR1PT CALLENV«"ATTACHPGM" NAME-"EDCCOMP" 

DDULST-"YES"/> 

<PARMS PARM KWD-" PARM2"></PARMS > 
<RC COND-"<-" val-"47> 
<!-- SYS IN -> 

<DD IOTYPE-"U" DDNAME-"&DD_COMPUNCH."> </DD> 
<!-- SYSUN-> 

<DD IOTYPE-"0" RECFM-"FB" LRECL-"80" 
REC\UM-"9999" DDNAME-"SYSUN" KEYREF-"OBJ"> </DD> 

</STEP> 



[0157] The process to merge listing outputs to one output 
is named "packlst.step." 

EXAMPLE 15 

[0158] 



[0161] Parallel to these activities, the second version of 
the product package PROD2 is finished after the completion 
of the system test STEST. The access to the elements in the 
local storage of the clients 25, 27, the access to the inter- 
mediate packages and the final product in the database 24, 



<!- Merge listings to oae LIST data set --> 
<STEP> 

<SCRIPT CAIXEN ISPFREXX" NAME-TACKLST* DDUST«"N07> 
cPARMS PARMKWD-"PARM3">&dd_Jst„comp; &dd_lst_cpre; 
(APPEND(&dd _Jst_conip;)></PARMS> 
<RC COND-"<=" val»"07> 

<DD> [OTYPE="0" DDNAME= u &dd_lst_comp;" KEYREF-"OUT2" 
RECFM="VBA" LRECL="137 f RECNUM= M 500000"><^DD> 
</STEP> 



[0159] Logic Project View Hierarchy and Workflow 

[0160] FIG. 6 shows the logical element hierarchy and 
data flow of a complex project related to a first and a second 
version of a product. Each block in FIG. 6 represents a data 
unit. The development of a product starts on the low level in 
groups DEVA, DEVB and TEAM. These groups represent 
the editable data units where elements may be created, 
modified or updated. Each of the units DEVA and DEVB is 
assigned to a single user, while unit TEAM is assigned to a 
team of users. The next higher blocks DEVTA, DEVTB and 
TEAMT are assigned to the test of the elements from DEVA, 
DEVB and TEAM. No modifications of the product ele- 
ments are permitted in the test level. The next higher levels 
represent a function test FTEST and a system test STEST of 
the second version of the product resulting from the ele- 
ments treated and tested on the lower levels. Al this point of 
time, the first version of the product PRODI is already 



and the linking between these components is controlled by 
the XSCML processor 22, while for the treatment of the 
contents of these components different languages such as 
REXX, C++, JAVA or PEARL may be used. The block 
DEVTB comprises a subblock 61 which represents delta 
elements of DEVTB data. This does permit an undone step 
if required by replacing processed data by the previous data. 
The blocks TEAMT, PRODI, PROD2 and FDCPRODI have 
corresponding subblocks 62, 63, 64 and 65. 

[0162] FIG. 7 shows a section of the process flow of the 
project according to FIG. 6 in more detail. By using the 
project meta data 41 (FIG. 4A), the XSCML processor 22 
controls, in an edit subsection 70, step 71 to investigate the 
validity and correctness of the project data and step 72 to 
assign the project to the development unit DEVA. The result 
of the editing process, which may be a product element, is 
treated in an evaluation subsection 73 wherein in step 74 the 
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result of DEVA is justified and signed off in step 75. As 
indicated by arrow 76, the XSCML processor 22 controls the 
move of the result of DEVA to DEVTA where it is tested by 
means of step 77 in a test section 78 of the data flow. 

[0163] The access rules to level and to actions are also 
defined via the XSCML syntax as part of the project 
definitions 40 shown in a simplified Example 16 which 
would be a part of Example 1: 



EXAMPLE 16 



[0164] 



-continued 



<ACT10N PGM-** ABC" PARM-**A B C /> 
</LEVEL> 



</PROCESS> 

<FROCESS STEP-" Verify" NEXT-' 

</PROCESS> 
</PROCESSFLOW> 



<ACCESS> 
<USER> 

<NAME> Smith, Joe 
<USER[D> JOE 

<ACTTON TYPE-" LANG" NAME-"CPP" RULE- M ...7> 
</USER> 

<USERGROUP NAME-"Developers"> 

<USERIDS> JOE </USER[DS> 
<7USERGROUP> 

<LEVEL NAME-" DEVA DEVTA" USERIDS-"JOE" ACCESS-"UPDATE" 

<ACTlON TYPE-" PROMOTE" RULE-"..."/> 
<^LEVEL> 

<LEVEL NAME-TEAM TEAMT* USERGROUPS-"Dcvclopcrs*' 
</LEVEL> 

<TYFE NAME-" CP P" USERIDS="JOE" ACCESS="READ" 

<ACTlON TYP E=" UPDATE" RULE="...7> 
</TYPE> 

<TYPE NAME="*** USERIDS="JOE" ACCESS« M UPDATE" 

<ACTTON TYP E=" UPDATE" RULE="...."/> 

</TYPE> 
</ACCESS> 



[0165] Those access rules are on top of built-in access 
rules of the XSCML system. The main goal is to ensure 
integrity and control of the data managed in an XSCML 
system. The level of access definition is not part of the 
invention but only the principle to provide this information 
also via the process definition syntax. 

[0166] It follows an example of a process flow definition 
as part of the project definition Example 1: 

EXAMPLE 17 

[0167] 



<PROCESSFLOW> 

<PROCESS STEP-"[nvestignte" NEXT-" Assign" INITCAL> 
<ACTTON PGM-"IJK"> 
</PROCESS> 

<PROCESS STEP-" Assign" NEXT- M Justify"> 
< LEVEL NAME-**DEV%"> 

<ACTtON POM-"ABC" PARM»"A B C" /> 
</LEVEL> 

<LEVEL NAME="TEAM"> 

<ACTlON POM-"ABC PARM-"0 P J" /> 
</LEVEL> 
</PROCESS> 

<PROCESS STEP--Justify" NEXT-"Sign Off"> 
</PROCESS> 

<PROCESS STEP--Sign OCT NEXT=** Verify" > 
<LEVEL NAME-"DEV%T*> 



[0168] The process flow may be more complex like a state 
machine with branches, loops and self references defined by 
the XSCML syntax and not only straight forward processes 
as the Example 17 shows. 

[0169] FIG. 8 relates to the physical representation of the 
product elements of a project and their definitions as stored 
in the sections 42 and 43 of the database 24. In FIG. 8, a 
block 80 includes the project definition. This block corre- 
sponds to section 45 of the database (FIG. 4A). Project view 
edit data 81 including the project model source is parsed, 
transformed and assigned to the project definition data. A 
block 82 comprises the project meta data including project 
status data and element relations and package relations. The 
project status data also specifies the language of the ele- 
ments which is shown in block 83 for the model elements A, 
B and C which are written in COBOL, CPP and PU, 
respectively, and also for the macro elements A, B and C 
which are written in COBOLMAC, PLIMAC and HPP, 
respectively. The blocks 82 and 83 correspond to section 41 
of the database. A block 84 which corresponds to the 
sections 42 and 43 of the database comprises a plurality of 
project groups each including all elements of a certain 
category. Element categories are "module,""makro,""load, 
""object code" or "code listings/' The XSCM processor 22 
of FIGS. 4A and 4B is represented in FIG. 8 by block 86 
and receives project view information from the project 
definitions 80 and controls the access to the elements 
indicated shown in block 84. 
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[0170] FIG. 9 shows the logical element hierarchy and 
workflow of a complex project comprising multiple hierar- 
chies for two different products A and B which may be 
developed in the same location by separate teams of devel- 
opers who are working in parallel. For both projects A and 
B, the same software configuration framework is used under 
the control of the XSCML processor 22 as described with 
reference to the FIGS. 6 and 7. The structure of the 
hierarchy relationship between the blocks shown in FIG. 9 
corresponds to that described in connection with FIG. 6. 

[0171] FIG. 10 shows the logical element hierarchy and 
workflow of a complex project which is produced by a 
distributed development by means of distributed computer 
systems 1, 2 and 3 designated in FIG. 10 by blocks 100, 101 
and 102. As already described in connection with FIG. 3, 
these systems may be located a far distance from each other. 
Each of the systems 100, 101 and 102 comprises a first 
server 20 including an XSCML processor 22 and a database 
24 and preferably a second server 26 for supporting build 
operations. System 102 comprises the edit section with the 
units DEVA, DEVB and TEAM which correspond to DEVA, 
DEVB and TEAM in FIG. 6. Furthermore, system 102 
comprises the edit test section with the units DEVTA, 
DEVTA and TEAMT which correspond to DEVA, DEVB 
and TEAMT in FIG. 6. System 102 also performs the test 
of fixes by FIXTEST1 of the first version of the product 
which corresponds to FIXTEST1 in FIG. 6. System 101 
performs the functions test FTEST and the system test 
STEST of the second version of the same product corre- 
sponding to the FTEST and STEST in FIG. 6. In system 
100, the product versions PRODI and PROD2 are admin- 
istrated according to PRODI and PROD2 in FIG. 6. System 
100 also performs the test of fixes FLXPROD1 of the first 
version according to FIXPROD1. The data flow in the 
systems 100, 101 and 102 corresponds to the data flow in the 
system shown in FIG. 6. In each of these systems, the data 
flow and the processes are controlled by the local XSCML 
processor. 

[0172] As shown in FIG. U, a project model 110 defined 
in the XSCML syntax is loaded into a master system 111 
which may be a separate system or one of the systems 112, 
113 and 114. As a first step, the XSCML processor 22 of the 
master system 111 performs a parsing and validating of the 
model loaded and checks the model on integrity. Copies of 
the model are than transferred through connections 115 to 
the local database 24 of each of the systems 112, 113 and 114 
where the model is locked. The connections 115 may be 
established via a communication network 34 such as the 
Internet or an Intranet. The locked models in the databases 
of the systems 112, 113 and 114 are then activated by 
commands on connections 116 which also may include the 
communication network to synchronize the systems with a 
new or updated model with a fallback possibility. FIG. 12 
shows the steps to initiate the XSCML system in a distrib- 
uted environment according to FIG. 11. In one of the 
systems 1, 2 or 3, a client starts the initiation process as 
indicated by step 120 to carry out a project. In step 121, the 
project definition, herein also called system view, is defined 
by creating the project definition via XSCML tags to 
describe the data flow through a logical element view based 
on a file system or object model system. This step includes 
a mapping to the memory of the XSCML processor system. 
The project definitions also include the process flow, the 
process definitions and the client access rights to data and 



processes. Furthermore, the project definition also deter- 
mines which of the distributed systems will be selected to be 
the master system. The creation is performed by using 
XSCML tags directly or by means of an XSCML tag editor. 
In step 122, the system view is validated. For this purpose, 
the initiating client passes the project definition to the 
XSCML processor of the master system. The XSCML 
processor of the master system is the administrator interface 
to the clients of distributed XSCML systems. The XSCML 
processor of the master system validates the project defini- 
tion for correctness including a check of the tags on cor- 
rectness and a check on the consistency of the definitions. In 
cases when errors are found, the client has to correct the 
project definition until the validation confirms the project 
definition. Step 123 performs a loading of the validated 
system view in the XSCML processors of the distributed 
systems. The XSCML processor of the master system first 
ensures that the validation step is successfully performed 
and then stores the project definition in the database 
assigned to the XSCML processor of the master system. The 
stored format may be different to the tag format but follows 
a one-to-one mapping. For the distributed systems, the 
project definition or relevant sections thereof are passed to 
the XSCML processors of the distributed systems for local 
validation. If the local validation is successful, the project 
definitions are stored in the local system and locked, where 
each system may store the related definitions in its propri- 
etary format with a one-to-one mapping relation of the tags 
based definition. The master system controls the correctness 
of all local system validations before the next step can be 
done. If more than one system view is defined, the system 
views are checked against each other for consistency. 

[0173] Step 124 activates the stored system view. The 
initiating client requests the XSCML processor of the master 
system to activate the project definitions stored there. The 
activation includes a preparation of the physical environ- 
ment as defined in the project definition. The process may 
involve the creation of files and databases and an update of 
the security system related to them. For the distributed 
systems, the master system initiates the activation of the 
involved distributed systems which will their environment 
as defined in their stored and locked project definitions. If all 
systems indicate the successful activation, the lock is taken 
of the project definitions is taken away. The local client is 
then enabled to work on the project as defined in the project 
definitions which work may involve to manage the project 
definitions in step 125 and to perform user client actions by 
step 126. 

[0174] Step 125 is shown in more detail in FIG. 13. It 
includes a system view update step 139 to implement 
changes of an existing project definition by a client request 
to retrieve from the XSCML processor of the master system 
the current project definition. That XSCML processor 
returns this project definition in the tag format and locks it 
in the update mode. The client may then do all actions 
provided by the system view definition step 121. Step 131 is 
followed by a new validation step 132 as described above 
after which a refresh system view step 133 is performed 
which sends the validated updates of the project definition to 
the XSCML processor of the master system. The XSCML 
master processor ensures that the changed project definition 
is loaded and activated in the same way described above for 
the steps 123 and 124. Dependent on the capability of the 
XSCML master processor, a delta format of the project 
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definition may be kept to allow a reproduction of the project 
definition before it was updated. Further steps shown in 
FIG. 13 include step 134 for deactivation of a system view 
so that client actions can temporarily not be performed, and 
step 135 for a complete removal of a system view so that it 
can not be used anymore. Step 125 also includes the 
definition of an alternate system view by step 136 which is 
followed by steps 137, 138 and 139 to validate, load and 
activate the alternate system view. Step 140 brings the 
control back to the calling client. 

[0175] FIG. 14 shows client actions of step 126. A client 
can issue an action command which activates at least one of 
the actions New, Check-out, Edit, Build, Promote, Delete or 
Query which are designated 142-148. To execute the action 
New, the XSCML processor uses the project definition and 
the meta data to set up and store a new element in the 
package and in the element memory on the edit group level. 
Simultaneously, the related meta data is updated. At least on 
language as defined in the meta data must be specified. A 
number of actions may be requested and carried out during 
this step according to the actions indicated in the process 
definitions associated to that element. 

[0176] To execute the action Check-out, the XSCML 
processor uses the project definition and the meta data to 
prepare an access to the package or element in its edit group 
and to set a lock to ensure an exclusive use of the package 
or element by that client. Based on the process definitions 
associated to that package or element, a number of actions 
may be requested and carried out during this step. The client 
may modify the package or element independent of the 
XSCML processor, and may select among the actions Save, 
Save-as, or check-in (close). 

[0177] To perform the action Save, the XSCML processor 
uses the project definition and the meta data to store the 
modified package or element in the package memory 43 or 
input element memory 44 (FIG. 4A) on the edit group level, 
and to update the related meta data. The action Save- as is 
similar to Save except that form an existing element or 
package a new element or package is created and stored 
under a new name and with the same XSCML properties of 
the existing element or package. Also the action Check-in is 
similar as Save except that the element or package is 
unlocked so that is accessible again by other clients. 

[0178] The action Edit 144 involves a check-out for the 
element or package to be edited and then calls an editor 
which has XSCML support built-in to edit an element of 
package in an edit group. The editor calls the XSCML 
actions New, Check-out, Save, Save-as, Check-in whenever 
appropriate edition functions are used by the client. The 
edition used is defined in the project definition and may be 
related to the type of an element or package. The edited 
Check-out element of package is checked-in by the XSCML 
processor. 

[0179] To initiate a Build action 145, the XSCML proces- 
sor uses the project definition and the meta data to determine 
if the type of the package to be build is "C,""L" or "HL." In 
case of a "C" type, the XSCML processor determines the 
related sources, parameters, process definition, outputs to be 
stored and the files needed for the Build action. It determines 
the status of the involved files and information needed for 
the Build action if it was changed by a previous Build action. 
If any changes are found, it transmits the complete build 



information to the defined build server 27 to execute "C" 
package Build action. The build server receives the build 
information for a package which contains input, parameter 
and output information and defines the build steps to be 
executed and the files needed for these steps. The build 
server does the allocation of the files needed and gets access 
to the sources needed to start the defined build action for the 
step to be executed. 

[0180] The build server stores all output elements indi- 
cated in the process definition back to the generated element 
memory. It also updates the meta data for the generated 
elements and creates a build information to contain the list 
of inputs generated elements and the dependencies and used 
parameters. The build server stores all outputs indicated in 
the process definition to user files for the build and error 
analysis in case that at least one build step failed. 

[0181] In case of a "L" type, the XSCML processor 
performs the action Resolve Build references to packages 
which scans the package for references to other build 
packages and issues a new action Build for each referenced 
build package which is not yet checked for a Build. There- 
after, the XSCML processor determines the related outputs 
as generated by the referenced packages to be used as input 
to the build process, further the parameters, process defini- 
tion, outputs to be stored, and files needed for the Build 
action. Before the "L" package Build action is started, a 
check is made for the referenced packages generating the 
elements to be used as input if a rebuild is needed. It 
determines the state of the involved files and information 
needed for the build if it changed from a successfully 
executed previous build. In this case, no build request is 
issued. If any changes are found, it transmits the complete 
build information to the defined build server to execute the 
a L" package Build. 

[0182] In case of an action Build for an "HL" type 
package, the XSCML processor performs the action Resolve 
Build references to packages. 

[0183] To execute the action Promote 146, the XSCML 
processor uses the project definition and the meta data to 
determine the elements and packages referenced to the 
package to be promoted and if they are located in the 
promote group from where the Promote action is issued. It 
also determines the group to which the promotion shall take 
place and their location. The Promote action creates copies 
of all referenced elements and packages to the next higher 
group and deletes them in the current group. The Promote 
action only moves successfully build packages. In a distrib- 
uted environment, a communication between the XSCML 
processors of the distributed systems takes place to synchro- 
nize their memories. 

[0184] To execute the action Delete 147, the XSCML 
processor uses the project definition and the meta data to 
determine the elements and packages to be deleted. To 
execute the action Query 148, the XSCML processor uses 
the project definition and the meta data to determine the 
elements and packages to the specified query to determine 
the information. The Query action allows an extensive 
retrieval of information stored in the packages, elements, 
project definitions and meta data. 

[0185] While the invention is described with reference to 
various embodiments and examples, modifications or other 



03/15/2004, EAST Version: 1.4.1 



US 2002/0040469 Al 



18 



Apr. 4, 2002 



embodiments of the invention are within the scope of the 
invention as defined in the claims. 

What is claimed is: 

1. A method of configuring software, the method com- 
prising the steps of: 

utilizing a common software configuration markup lan- 
guage in a computer system including at least one 
server which is connected to a plurality of client 
computers, the server having a memory for storing 
product elements which may be linked together to form 
at least one version of a software package, and further 
for storing processes usable by the clients to at least one 
of maintain the product elements and develop new 
product elements, and tools usable by the clients to at 
least one of define, maintain and update relations 
between product elements; 

wherein the common software configuration markup lan- 
guage is operable to at least one of define a project, 
perform a memory access to at least one of product 
elements and packages, map one or more of the pro- 
cesses and tools to one ore more library systems, and 
define relations between the product elements, and 
further wherein a framework associated with the com- 
mon software configuration markup language is sys- 
tem-independent. 

2. The method of claim 1, further comprising at least one 
of the steps of; 

generating and storing a project definition which defines 
data flow, process flow and process definition of a 
project by using the common software configuration 
markup language; 

generating and storing the software configuration frame- 
work by using the project definition and the process 
definition to describe the product elements and pro- 
cesses and define their access parameters and their 
relations; 

mapping of the product elements, processes and tools to 
the one ore more library systems by using the common 
software configuration markup language; 

storing the product elements, processes and tools in the 
memory of the at least one server; 

assigning the product elements, processes and tools in 
storage to the software configuration framework; and 

calling selected ones of the product elements, tools and 
processes by at least one of the clients using commands 
of the common software configuration markup lan- 
guage, whereby another programming language may be 
used to at least one of develop, update and test the 
contents of the product elements called. 

3. The method of claim 1, wherein the common software 
configuration markup language is an extensible markup 
language. 

4. The method of to claim 1, wherein the common 
software configuration markup language is based on the 
Extensible Markup Language (XML). 

5. The method of claim 1, further comprising the step of 
generating commands in the common software configura- 
tion markup language via a control program in the server, 
wherein the control program is part of the software configu- 
ration framework. 



6. The method of claim 1, wherein the common software 
configuration markup language is used for defining a project 
to one of develop and update a software product in a first 
server via the steps of accessing project definition data and 
data on project states, user access rights and element rela- 
tions in a database connected to the first server to set up the 
project, and repeatedly accessing and updating project status 
data in the database. 

7. The method of claim 1, wherein the common software 
configuration markup language is used for preparing an edit 
action for product elements comprising the steps of invoking 
an editor to which the product and process definition, 
element states and relations among elements are provided by 
a control program in a first server, wherein the control 
program is associated with the software configuration frame- 
work, and accessing processes and tools in the database for 
one of developing new product elements and modifying and 
updating existing product elements by the control program. 

8. The method of claim 7, wherein the editor uses a 
language which is independent of the common software 
configuration markup language. 

9. The method of claim 1, wherein the common software 
configuration markup language is used for building pack- 
ages of product elements in a second server, connected to a 
database, via the steps of accessing processes and tools in 
one of a memory of the second server and the database so as 
to compile and link product elements to form program 
packages. 

10. The method of claim 1, further comprising the step of 
generating self -documenting product elements and packages 
of product elements, and updates thereof, via the common 
software configuration markup language. 

11. The method of claim 2, wherein the storing step 
comprises the step of storing the system-independent soft- 
ware configuration framework in memories of a plurality of 
geographically distributed computer systems which are con- 
nected together through a communication network, and 
wherein the assigning step comprises the step of assigning 
the product elements, processes and tools to the system- 
independent software configuration framework in the 
memories of each of the distributed computer systems. 

12. The method of claim 11, wherein each of the distrib- 
uted computer systems generates commands in the common 
software configuration markup language by a control pro- 
gram which is part of the software configuration framework. 

13. The method of claim 11, further comprising the steps 
of editing product elements in each of the distributed sys- 
tems by using a first server which is connected to a locally 
installed database, and building packages by a second server 
connected to the database. 

14. The method of claim 11, wherein the calling step 
comprises calling elements, tools and processes by at least 
one of the clients attached to the servers in each of the 
distributed systems, and editing the elements by using one of 
same and different programming languages which are inde- 
pendent of the common software configuration markup 
language. 

15. The method of claim 11, further comprising the step 
of transferring changes of the product elements, which result 
from processing of the product elements by each of the 
distributed systems, to the other distributed systems. 

16. The method of claim 11, wherein one of the distrib- 
uted systems is used as master system, the memory of which 
contains project definition and process definition data in the 
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common software configuration markup language, the data 
being used by a control program to initiate the software 
configuration framework. 

17. Apparatus for configuring software, the apparatus 
comprising: 

one or more processors operable to utilize a common 
software configuration markup language in a computer 
system including at least one server which is connected 
to a plurality of client computers, the server having a 
memory for storing product elements which may be 
linked together to form at least one version of a 
software package, and further for storing processes 
usable by the clients to at least one of maintain the 
product elements and develop new product elements, 
and tools usable by the clients to at least one of define, 
maintain and update relations between product ele- 
ments; 

wherein the common software configuration markup lan- 
guage is operable to at least one of define a project, 
perform a memory access to at least one of product 
elements and packages, map one or more of the pro- 
cesses and tools to one ore more library systems, and 
define relations between the product elements, and 
further wherein a framework associated with the com- 
mon software configuration markup language is sys- 
tem-independent. 

18. The apparatus of claim 17, wherein the one or more 
processors are further operative to at least one of: 

generate and store a project definition which defines data 
flow, process flow and process definition of a project by 
using the common software configuration markup lan- 
guage; 

generate and store the software configuration framework 
by using the project definition and the process defini- 
tion to describe the product elements and processes and 
define their access parameters and their relations; 

map of the product elements, processes and tools to the 
one ore more library systems by using the common 
software configuration markup language; 

store the product elements, processes and tools in the 
memory of the at least one server; 

assign the product elements, processes and tools in stor- 
age to the software configuration framework; and 

call selected ones of the product elements, tools and 
processes by at least one of the clients using commands 
of the common software configuration markup lan- 
guage, whereby another programming language may be 
used to at least one of develop, update and test the 
contents of the product elements called. 

19. The apparatus of claim 17, wherein the common 
software configuration markup language is an extensible 
markup language. 

20. The apparatus of to claim 17, wherein the common 
software configuration markup language is based on the 
Extensible Markup Language (XML). 

21. The apparatus of claim 17, wherein the one or more 
processors are further operative to generate commands in the 
common software configuration markup language via a 
control program in the server, wherein the control program 
is part of the software configuration framework. 



22. The apparatus of claim 17, wherein the common 
software configuration markup language is used for defining 
a project to one of develop and update a software product in 
a first server via the steps of accessing project definition data 
and data on project states, user access rights and element 
relations in a database connected to the first server to set up 
the project, and repeatedly accessing and updating project 
status data in the database. 

23. The apparatus of claim 17, wherein the common 
software configuration markup language is used for prepar- 
ing an edit action for product elements comprising the steps 
of invoking an editor to which the product and process 
definition, element states and relations among elements are 
provided by a control program in a first server, wherein the 
control program is associated with the software configura- 
tion framework, and accessing processes and tools in the 
database for one of developing new product elements and 
modifying and updating existing product elements by the 
control program. 

24. The apparatus of claim 23, wherein the editor uses a 
language which is independent of the common software 
configuration markup language. 

25. The apparatus of claim 17, wherein the common 
software configuration markup language is used for building 
packages of product elements in a second server, connected 
to a database, via the operation of accessing processes and 
tools in one of a memory of the second server and the 
database so as to compile and link product elements to form 
program packages. 

26. The apparatus of claim 17, wherein the one or more 
processors are further operative to generate self-document- 
ing product elements and packages of product elements, and 
updates thereof, via the common software configuration 
markup language. 

27. The apparatus of claim 18, wherein the storing opera- 
tion comprises storing the system-independent software 
configuration framework in memories of a plurality of 
geographically distributed computer systems which are con- 
nected together through a communication network, and 
wherein the assigning operation comprises assigning the 
product elements, processes and tools to the system-inde- 
pendent software configuration framework in the memories 
of each of the distributed computer systems. 

28. The apparatus of claim 27, wherein each of the 
distributed computer systems generates commands in the 
common software configuration markup language by a con- 
trol program which is part of the software configuration 
framework. 

29. The apparatus of claim 27, wherein the one or more 
processors are further operative to edit product elements in 
each of the distributed systems by using a first server which 
is connected to a locally installed database, and building 
packages by a second server connected to the database. 

30. The apparatus of claim 27, wherein the calling opera- 
tion comprises calling elements, tools and processes by at 
least one of the clients attached to the servers in each of the 
distributed systems, and editing the elements by using one of 
same and different programming languages which are inde- 
pendent of the common software configuration markup 
language. 

31. The apparatus of claim 27, wherein the one or more 
processors are further operative to transfer changes of the 
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product elements, which result from processing of the prod- 
uct elements by each of the distributed systems, to the other 
distributed systems. 

32. The apparatus of claim 27, wherein one of the 
distributed systems is used as master system, the memory of 
which contains project definition and process definition data 
in the common software configuration markup Language, the 
data being used by a control program to initiate the software 
configuration framework. 

33. A software configuration system for the use in a 
computer system including at least one server which is 
connected to a plurality of client computers, the server 
having a memory for storing product elements which may be 
linked together to form at least one version of a software 
package, and further for storing processes usable by the 
clients to at least one of maintain the product elements and 
develop new product elements, and tools usable by the 
clients to at least one of define, maintain and update relations 
between product elements, the system comprising: 

means for storing a project definition which defines data 
flow, process flow and process definition of a project by 
using a common software configuration markup lan- 
guage which is adapted to serve as a meta syntax for 
defining a project and processes to perform the project, 
for mapping of the processes and tools to a database, 
and for accessing product elements in the database; 

means for generating and storing a software configuration 
framework by using the project definition and the 
process definition to describe the product elements and 
processes and define their access parameters and their 
relations; 

means for mapping of the product elements, processes 
and tools to the one ore more library systems by using 
the common software configuration markup language; 

means for storing the product elements, processes and 
tools in the memory of the at least one server; 

means for assigning the product elements, processes and 
tools in storage to the software configuration frame- 
work; and 

means for calling selected ones of the product elements, 
tools and processes by at least one of the clients using 
commands of the common software configuration 
markup language, whereby another programming lan- 
guage may be used to at least one of develop, update 
and test the contents of the product elements called. 

34. An article of manufacture for configuring software, 
the article comprising a machine readable medium contain- 
ing one or more programs which when executed implement 
the steps of: 



utilizing a common software configuration markup lan- 
guage in a computer system including at least one 
server which is connected to a plurality of client 
computers, the server having a memory for storing 
product elements which may be linked together to form 
at least one version of a software package, and further 
for storing processes usable by the clients to at least one 
of maintain the product elements and develop new 
product elements, and tools usable by the clients to at 
least one of define, maintain and update relations 
between product elements; 

wherein the common software configuration markup lan- 
guage is operable to at least one of define a project, 
perform a memory access to at least one of product 
elements and packages, map one or more of the pro- 
cesses and tools to one ore more library systems, and 
define relations between the product elements, and 
further wherein a framework associated with the com- 
mon software configuration markup language is sys- 
tem-independent. 

35. The article of claim 34, further comprising at least one 
of the steps of: 

generating and storing a project definition which defines 
data flow, process flow and process definition of a 
project by using the common software configuration 
markup language; 

generating and storing the software configuration frame- 
work by using the project definition and the process 
definition to describe the product elements and pro- 
cesses and define their access parameters and their 
relations; 

mapping of the product elements, processes and tools to 
the one ore more library systems by using the common 
software configuration markup language; 

storing the product elements, processes and tools in the 
memory of the at least one server; 

assigning the product elements, processes and tools in 
storage to the software configuration framework; and 

calling selected ones of the product elements, tools and 
processes by at least one of the clients using commands 
of the common software configuration markup lan- 
guage, whereby another programming language maybe 
used to at least one of develop, update and test the 
contents of the product elements called. 

* + * * * 
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